AMENDMENT NO. 2 JULY 2020 
TO 


IS 16833 : 2018 AUTOMOTIVE TRACKING DEVICE 
( ATD ) AND INTEGRATED SYSTEMS 


[ Page 2, clause 4.22 (see also Amendment No. 1) | — Insert the following 
at the end of the clause: 


*4.23 Time to First Fix (TTFF) — Time to first fix describes the time required for 
a tracking device to acquire adequate satellite signals and related data (almanac 
and ephemeris data) to compute location. 


4.24 Type — Components, separate technical units or assemblies of different 
‘Type’ means components, or assemblies which differ in such essential respects 
as trade name or mark and other technical details (requirements) as given in 
individual standard." 


(Page 2, clause 4.6) — Delete. 
(Page 2, clause 4.7) — Delete. 


[ Page 3, clause A-2.1 (1) (see also Amendment No. 1) | — Substitute the 
following for the existing: 


‘1) The system should support any operational GNSS system (Location, speed, 
heading, time stamp) data polling and capable of sending this data at a frequency 
shall be 5 sec during vehicle operation and not less than 10 minutes in sleep/ 
Ignition off a per protocol defined in A-4. 


Device shall be capable for operating in L and/or S band and include support 
for NAVIC/IRNSS (Indian Regional Navigation Satellite System) for devices 
installed on vehicles on or after 1st April 2019. However, ATD devices shall be 
compliant as per other GNSS constellation in the interim period." 


Price Group 8 


[ Page 3, clause A-2.1 (5) (see also Amendment No. 1) | — Substitute the 
following for the existing: 


*5) The system's GNSS module shall have an acquisition sensitivity of equal to 
or better than (-) 145 dBm with GNSS/ (-)140 dBm with IRNSS (NAVIC as 
applicable.).’ 


[ Page 3, clause A-2.1 (6) (see also Amendment No. 1) | — Substitute the 
following for the existing: 


*6) The system's GNSS module shall have a tracking sensitivity equal to or better 
than (-) 160 dBm with GNSS / (-)153 dBm with IRNSS (NAVIC as applicable). 


[ Page 3, clause A-2.1 (9) (see also Amendment No. 1) | — Substitute the 
following for the existing: 


*9) Should support standard digital I/O: 4 Digital, 2 Analogue Input and 1 Serial 
Communication (for example, RS232) for interfacing external systems (for 
example, Digital input for Emergency request button interfacing) and output for 
triggering other devices like hooter/flash light, etc." 


[ Page 3, clause A-2.1 (10) (see also Amendment No. 1) | — Substitute the 
following for the existing: 


*10) In case of use on buses it will provide the following additional information: 


Provide GPS data via RS 232/ RS485/CAN Ethernet to other On —Bus 
Devices (Such as PIS, CCTV system, ticketing system, etc.) 


a 


wa 


b) Receive Route Number information from other On-Board devices and 


transmit to back end (Optional). 

Provide CAN interface to send relevant Vehicle Health data to Back end 
(Optional). 

Provision to provide Alerts Data’ VHMD to Other On-Bus devices 
(Optional). 

Provide Cellular module data transfer gateway to other on-bus devices 
(Optional).* 


wm 


c 


— 


d 


— 


e 


— 


[ Page 4, clause A-2.1 (13) (see also Amendment No. 1) | — Substitute the 
following for the existing: 
*13) The system's Cellular module should have: 

a) Multi slot GPRS with in-built quad-band GPRS module/modem, 

b) GPRS class 10 or above, 


c) Support Embedded SIM/UICC (As per as per GSMA guidelines / DoT 
(TEC) Guidelines) to cater to the automotive operational requirement 
such as vibration, temperature and humidity and provide long life span 
with at least 10 years life and more than 1 million read/write cycles, and 


d) GPRS module and Embedded SIM/UICC: 
1) Shall support SMS, Data (GPRS, TCP/IP); and 
2) Support multiple network OTA switching (on-demand/ automatic) 
capabilities.’ 


[ Page 4, clause A-2.1 (14) (see also Amendment No. 1) | — Substitute the 
following for the existing: 


*14) Device shall be manufactured by manufacturer whose quality management 
system has been certified for compliance to ISO / TS 16949 or ISO 9001 or any 
equivalent National or International standard.* 


[ Page 4, clause A-2.1 (17) ] — Substitute the following for the existing: 


*17) System shall be capable to operate with vehicle battery input voltage 12V 
d.c. and or 24V d.c." 


[ Page 4, clause A-2.1 (see also Amendment No. 1) | Insert the following at 
the end of the clause: 


*25) Device shall have sleep mode current < 50mA.’ 


[ Page 4, clause A-2.2 (see also Amendment No. 1) | — Substitute the 
following for the existing: 


‘The device at least support below parameters should be configurable over 
the air (through SMS or Cellular). The update shall be allowed only over an 
‘authenticated’ channel: 
a) Setting/ Change of the Primary or Secondary IP and port number, 
b) Setting/Change of the APN, 
c) Set configuration parameter like sleep time, over speed limit, harsh 
braking, harsh acceleration, rash turning threshold limits etc., 
d) Emergency control and Activation/ Health Check control SMS Centre 
Number(s), 
e) Configuring the Vehicle registration number, 
f) Configuring the frequency of data transmission in normal/Ignition state/ 
OFF state sleep mode/health check message on SMS/Emergency state, 
etc, 


g) Configuration of time duration for emergency state, 
h) Capacity to reset device, 


j) Command to get the IMEI (International Mobile Station Equipment 
Identity)/ Health Status of the device, 


k) CLR: For clearing certain commands, alarms, alerts etc. except 
emergency alert. 


SET: For setting parameters, and 


GET: For enquiring regarding the parameters such as mobile number, 
GSM strength, vehicle number and other important parameters. 


After each SET, GET, CLR command the device should send alert to Backend 
Control Centre, as mentioned in A-4 Alert (xii Table 2A), giving the details of 
Mode, mobile no/ IP of control centre sending commands.’ 


[ Page 6, Table 1, SI No. v) (see also Amendment No. 1) | Insert the following 
at the end in col (3) description: 
*HB - Harsh Breaking, 
HA - Harsh Acceleration 
RT = Rash Turning? 


[ Page 7, Table 2, SI No. 1), col 3] Substitute the following in col (3): 
*Message: Location Update (history) 
Remarks: Would be sent, if Cellular is not available at the time of sending the 


message.’ 


[ Page 8, clause A-4.2, Informal Table, ii), iii) and iv) ] Substitute the 
following for the existing text: 


SI No. Attribute Value / Description Size 


ii) Packet type Message Types supported. Character, 2 bytes 
Emergency Message (EMR) or 
Stop Message (SEM) 


iii) IMEI No. Unique ID ofthe Vehicle (IMEI Character, 15 bytes 
Number) 


iv) Packet status NM — Normal packet, SP — Character, 2 bytes 
Stored packet 


[ Page 8, clause A-4.2.3 (see also Amendment No. 1) | — Substitute the 
following for the existing clause: 


*A-4.2.3 Activation SMS Format from State Backend/ Common Layer to 
Device and Health Check Random Messages from State Backend/ Common 


Layer to Device 


from Device to Backend System 


Activation and Health Check Response SMS Format 


Field Name Characters Activation Health Check 
Example Example 
Header 5 ACTVR HCHKR 
Separator 1 ! 
Random code 6 343434 474747 
Separator 1 ; s 
Vendor ID 4 
Separator 1 n 5 
Firmware version 6 V1.6.1 V1.6.1 
Separator 1 " F 
IMEI 15 012345678912345 | 012345678912345 
Separator ; ; 
Alert ID 2 1 1 
Separator ; š 
Latitude 12 14.034533 14.034533 
Separator 1 a ; 
direction 1 N N 
Separator 1 : 
Longitude 12 79.32045 79.32045 
Separator 1 ; " 
Direction 1 E E 
Separator 1 ; " 
GPS fix 1 1 1 
Separator 1 ; 


Activation and Health Check Response SMS Format 
from Device to Backend System 


Field Name Characters Activation Health Check 
Example Example 
Date and Time 15 16112018 120317 | 16112018 120317 


Separator 


E 


E 


Heading 


263.19 


263.19 


Separator 


E 


E 


Speed 


25.4 


25.4 


Separator 


, 


, 


GSM strength 


23 


23 


Separator 


Country Code (MCC) 


Separator 


Network Code (MNC) 


Separator 


LAC 


d6d6 


d6d6 


Separator 


Main Power 


Separator 
IGN Status 


1 


1 


Separator 


5) 


$ 


Battery Voltage 


Separator 


24.6 


E 


24.6 


> 


Frame Number 


100000 


100000 


Separator 


Vehicle mode 


l2|[—|o|—|»|—i—|—|—|—|m —||m|—|:w-|—|-mnm|—|-|j—io|— 


E 


ID 


E 


ID 


Total Characters 


— 
U 
O 


(Page 9, clause A-5.1) — Substitute the following for the existing clause: 


‘A-5.1 VLT Device Location 


The VLT system shall be mounted in a suitable location such a way that it is not 
easily accessible /exposed to passengers. 


This requirement shall not be applicable in case of combined systems VLT with 
HMI (Human Machine Interface) display in front of driver.’ 


[ Page 9, clause A-5.4 (see also Amendment No. 1) | — Substitute the 
following for the existing clause: 


*A-5.4 Emergency Button Requirements and Physical Mounting 


Emergency button(s) shall be fitted in such a way that every passenger including 
driver shall be able to access the Emergency button(s). Passenger Car shall have 
at least one emergency buttons on each passenger row easily accessible by each of 
the passenger. There shall also be one dedicated emergency button for the driver 
row. Passenger Transport bus shall have emergency buttons at locations easily 
visible and accessible to all the passengers such as every 2 m on both the sides 
on passenger seating area. For seats reserved for ladies there shall be a dedicated 
panic button for each row. It shall be permissible to have a single emergency 
button for two successive ladies’ rows on both sides of the vehicle provided each 
lady passenger in either rows are able to reach and operate the emergency button. 


In case of passenger transport bus which has a glass window covered between 
two pillars having pitch 2 m or more, the emergency buttons shall be provided on 
each pillar National Permit Trucks, shall have one dedicated emergency button 
for the driver row.’ 


[ Page 9, clause A-6 (see also Amendment No. 1) ] — Substitute the following 
for the existing clause: 


*A-6 DEVICE LEVEL FUNCTIONAL, PERFORMANCE AND 
DURABILITY TESTS 


a) The tests have been classified as Type Tests and Acceptance Tests. 
b) The tests have been divided into categories. 


The devices can be tested and certified from the testing agencies referred to in rule 
126 of the CMVR for compliance to the rule 125 H of CMVR.’ 


[ Page 9, clause A-6, (a) and (b) (see also Amendment No. 1) | — Delete. 


[ Page 9, clause A-6.1 (see also Amendment No. 1) | — Substitute ‘List of 
Tests’ for “Type Tests’. 


(Page 9, clause A-6.1) — Delete ‘The following shall constitute type test:’ 
(Page 9, clause A-6.2) — Delete. 


[ Page 11, clause A-7.1 (f) and (g) (see also Amendment No. 1) ] — Substitute 
the following for the existing matter: 


*f) Acquisition sensitivity test — Acquisition sensitivity refers to the minimum 
signal level at which the device is able to successfully perform a cold start 
TTFF. The acquisition sensitivity test is a simulated signal test. A device cold 
start is performed, and the time to acquisition is measured. Signal levels are then 
progressively increased. Allow the receiver to successfully perform cold start 
TTFF. The minimum signal level is referred as to be acquisition sensitivity. This 
signal strength is recorded. 


Acceptance Criteria: The acquisition sensitivity shall be minimum (-) 145 dBm 
with GNSS/ (-) 140 dBm with IRNSS (NAVIC as applicable.). 


g) Tracking sensitivity test — Tracking sensitivity refers to the minimum signal 
level at which the device is able to successfully maintain the location fix. The 
tracking sensitivity test is a simulated signal test. Test setup for the tracking 
sensitivity receiver test is as shown in Fig. 3. The device under this test is 
locked on to the simulator's output frequency and the simulator power output 1s 
lowered until the lock is lost. Multiple repetition of the test with different satellite 
geometries ensures that an accurate average measure is recorded. 


Acceptance Criteria: The tracking sensitivity shall be equal to or better than (-) 
160 dBm with GNSS / (-) 153 dBm with IRNSS (NAVIC as applicable).’ 


[ Page 12, clause A-7.1 (j) (see also Amendment No. 1) | — Substitute the 
following for the existing matter: 


*J On vehicle dynamic location test — VLT devices will be mounted on any 
target vehicle connected with vehicle battery. Target vehicle with VLT devices 
will be run for 10 km on pre-defined track/route to verify dynamic location test. 
VLT device PVT data shall be within + 12 m for more than 90 percent of the fixed 
location data." 


[ Page 13, clause A-7.2 (e) (see also Amendment No. 1) |] — Substitute ‘High 
Voltage Test’ for ‘Over voltage protection test? 


[ Page 14, clause A-7.3 (a) ] — Substitute ‘Dry Heat/High Temperature Test? 
for ‘High Temperature Test? 


[ Page 14, clause A-7.3 (g) (see also Amendment No. 1) | — Delete. 


[ Page 15, Table 4, SI No. 1v) (see also Amendment No. 1) | — Substitute the 
following for the existing matter: 


SI No. Field Description 
0) (2) (3) 
iv) Packet Type Specify the packet type : 
NR = Normal 


EA = Emergency alert 

TA = Tamper alert 

HP = Health packet 

IN = Ignition on 

IF = Ignition off 

BD = Vehicle battery disconnect 
BR = Vehicle battery reconnect 
BL = Internal battery low 

HB = Harsh breaking, 

HA = Harsh acceleration 


RT = Rash turning 


[ Page 15, Table 5 (see also Amendment No. 1) ] — Substitute the following 
for the existing matter: 


SI Alert ID Message Remarks 
No. 
(1) (2) (3) (4) 
i) 1 Location Update Default message coming from each device 
ii) 2 Location Update (history) Would be sent, if GPRS is not available at 
the time of sending the message 
iii) 3 Alert — Disconnect from main If device is disconnected from vehicle 
battery battery and running on its internal battery 
iv) 4 Alert — Low battery If device internal battery had fallen below 


a defined threshold, indicating that device 
need to get a recharge 


SI Alert ID Message Remarks 
No. 
0) 2 (3) (4) 
v) 5 Alert — Low battery removed Indicate that vehicle internal battery is 
charged again 
vi) 6 Alert — Connect back to main Indicate that vehicle is connected back to 
battery main battery 
vii) 7 Alert — Ignition ‘ON’ Indicates that vehicle has started (ignition 
‘ON’) 
viii) 8 Alert — Ignition ‘OFF’ Indicates that vehicle has stopped (ignition 
‘OFF’) 
ix) 9 Alert — GPS box opened Optional message would be generated 
(Optional) indicating GPS box opened 
x) 10 Alert — Emergency state ‘ON’ When any of the emergency button is 
pressed 
x1) 11 Alert — emergency state ‘OFF’ When emergency state of vehicle is 
removed 
xii) 12 Alert Over the air parameter Alerts for any parameter is changed 
change over the air. Shall include the name/ 
value of parameter changed and source 
of command. Shall include the name/ 
value of parameter changed and source of 
command 
xiii) 13 Harsh braking Alert indicating for harsh braking. 
xiv) 14 Harsh acceleration Alert indicating for harsh acceleration 
xv) 15 Rash turning Alert indicating for rash turning 
Xvi) 16 Device tempered Alert Indicating Emergency button wire 


disconnect/ wire cut etc. 


[ Page 17, Table 6, SI No. iii) and iv) ] — Substitute the following for the 
existing matter: 


SI No. Attribute Value / Description Size 
(1) (2) (3) (4) 
iii) IMEI Number Unique ID of the Vehicle (IMEI  Character,15 bytes 
Number) 
iv) Packet Status NM - Normal packet, SP — Stored Character, 2 bytes 


packet 
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[ Page 17, Table 6, SI No. xvii) ] — Insert the following at the end of the table: 


SI No. Attribute Value / Description Size 
(D (2) (3) (4) 
xvii) End Character * 1 byte 


(Page 17, clause A-7.4) — Insert the following new clause: 


*A-8 CODE OF PRACTICE FOR IMPLEMENTATION OF VEHICLE 
LOCATION TRACKING (VLT) DEVICE, EMERGENCY BUTTON(S) 
AND COMMAND AND CONTROL CENTRES 


This Code (see Annex A) has been formulated for facilitating smooth 
implementation of vehicle location tracking (VLT) Device, emergency button(s) 
and command and control centers for the guidance of the stakeholders concerned. 


A-8.1 General 


a) The VLT device manufacturers will get their devices tested and certified 
from the testing agencies referred to in rule 126 of the CMVR for 
compliance to the rule 125 H of CMVR 


The backend system shall mean the backend command and control centre 
set up/ authorized by State/UT or VLT manufacturers, providing interface 
to various stakeholders/systems such as State emergency response centre, 
the transport department or Regional Transport Offices, Ministry of Road 
Transport and Highways and its designated agency, VAHAN (or any 
other State/UT system used for registration of vehicles and/or issuance of 
permits), VLT device manufacturers and their authorized dealers, testing 
agencies, permit holders, etc. In the absence of State/UT backend system, 
the registration, activation, health check and alert updates of VLT devices 
shall be through a common layer for update in VAHAN. 


b 


— 


The details of each VLT device (VLT device manufacturer code, device 
serial number, IMEI number, IccID number and other details as notified 
by the Central Government/State Government) shall be uploaded on 
the VAHAN directly or through backend system by the VLT device 
manufacturer using its secure authenticated access. 


The VLT device manufacturers or their authorized dealers shall install 
the VLT devices in vehicles and register/activate the devices along 
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c 


) 


d) 


e 


) 


g) 


h) 


j 


— 


with details of vehicle and permit holder on the corresponding backend 
systems in real time as per the process set out below 


The backend system/common layer will update the details of device in 
the VAHAN system against the respective vehicle record at the time of 
installation and registration/activation of VLT device. 


The VLT device manufacturers or their authorized dealers, at the time of 
installation of VLT device in vehicles, shall configure the IP address and 
SMS gateway details in the device for sending emergency alerts to the 
emergency response system of the State/UT concerned. 


The VLT device manufacturers or their authorized dealers, at the time of 
installation of VLT device in vehicles, shall configure the configuration 
parameters mentioned in Annex A in the device such as IP address and 
SMS gateway details for sending required data to the backend system. 


The VLT device manufacturers shall ensure that a control mechanism is 
established for the secure data transfer from VLT to the backend system 
and that only the authorized devices transfer data to the backend system. 


The VLT device manufacturers shall also ensure that the mechanism 
for authenticating the vehicle owner and devices is followed as per the 
protocol specified in Annex A or such additional requirements as specified 
by the States/UTs. Authentication of vehicle shall be done through an 
OTP sent on vehicle owner's mobile number from the corresponding 
backend system. 


In case of press of an emergency button, the VLT device will send data 
directly to the emergency response system of the respective State/UT. In 
addition, the backend system will send the alert to the respective permit 
holder, as decided by the State/UT. 


VLT device manufacturers shall get their devices tested for conformity of 
production every year from the date of first certification, from the testing 
agencies referred to in Rule 126 of the CMVR. 


VLT device manufacturers shall get their backend systems certified for 
the States/UTs from the testing agencies referred to in Rule 126 of the 
CMVR/ STQC/NIC. 


The VLT device manufacturers or their authorized dealers, at the time of 
installation of VLT devices in vehicles, shall configure the VLT device to 
send a secure authenticated activation message directly to the State/UT 
backend system/common layer as per the details provided in A-4.2.3. 
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k) The VLT device manufacturers shall ensure that the Health Check 


m 


n 


) 


— 


parameters are configured in the VLT device to send health check 
messages, on request from the state/UT backend system/common layer, 
to the respective backend system through SMS as per reference protocol 
mentioned in this A-4.2.3. 


VLT device manufacturers or their authorized dealers shall provide 
comprehensive warranty/maintenance support for the VLT device and 
facilitate cellular connectivity in accordance with the guidelines issued 
by central government vide Motor Vehicles (Vehicle Location Tracking 
Device and Emergency Button) Order, 2018 as amended from time-to- 
time. 


The testing agencies will verify the conformity of production for the VLT 
devices as prescribed in A-8.4. 


A-8.2 Installation, Registration, Activation and Service Process for VLT 
Device 


a) VLT device manufacturers or their authorized dealers shall install VLT 


b 


Cc 


) 
) 


d) 


e 


g 


— 


wa 


devices on permit holder’s vehicles (only tested and approved model). 


VLT device manufacturers shall ensure necessary uploading/integration 
of the installation/activation data to the backend system/VAHAN. 


In case of any problem in updating VAHAN, it will be VLT device 
manufacturer’s responsibility to resolve the same. 


VLT device manufacturers or their authorized dealers will also provide 
necessary print of installation/activation report to permit holder from the 
respective backend system. 


Regional Transport Offices shall be able to verify the registration/ 
activation/functional status of VLT device in the VAHAN/corresponding 
backend system at the time of fitness testing. 


The permit holder will have option to check the installation and device 
working status in the VAHAN. 


The VLT device manufacture may offer value added services, in addition 
to the mandatory performance requirements to the permit holders as 
per the mutual agreement between them. Mandatory performance 
requirements shall mean the following: 


1) Uploading device data in VAHAN, 
2) Updating registration and activation data of VLT device, 
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3) Sending device health status to the backend system, 

4) Sending emergency alerts to the corresponding State/UT emergency 
response system, 

5) Sending over speeding alerts to the backend system, and 

6) Other performance requirements as per Annex A and as notified by 
central government vide Motor Vehicles (Vehicle Location Tracking 


Device and Emergency Button) Order, 2018 as amended from time- 
to-time. 


h) The VLT device manufacturers may create their own system to monitor 


their supplied devices, emergency button/s and connectivity working / 
nonworking status for managing warrantee / AMC and Cellular services. 


j) The VLT device manufacturers or their dealers will update the SIM 


numbers and their validity/renewal details in the backend system. 


A-8.3 VLT Device Manufacturers Backend Application/System 
Requirements 


In case VLT device manufacturer offers to provide its backend system for State/ 
UT, the same will need to meet the following requirements, in addition to those 
specified in A-2.4. 


a) The application will provide the ability to locate a vehicle at a given time. 


b) Facility to track defined vs. actual movement of vehicles, capture 


c 


) 


d) 


e 


g 


— 


— 


deviations if any (For vehicles where scheduled movement can be 
defined on GIS map). 


The application should provide ability to track vehicle location on map. 
The map engine and data should comply with applicable regulations 
including guidelines as set out by Survey of India from time-to-time. 


Facility for users to access and view position / location information 
on GIS maps near real-time through web interface with historic data 
displayed on maps. 


Facility for providing current information location on demand. 


Facility for playing back the recorded details of the vehicle movement 
along the authorized route (where applicable). 


Provide facility of alert generation for the following instances/which 
includes the following: 


1) Ability to define new alerts on specific events. 
2) From the on-board devices in case of tampering. 
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h) 


J) 


k 


— 


m 


wm 


n 


P 


— Ha 


ma 


q 


r) 


s) 


3) Speed exceeds the permissible limit. 
4) Vehicle moves out of its designated route or area. 
5) Data feed not received from the on-board device. 


Provide facility to define rules for alerts/ notification and their delivery 
mode like SMS, email, pop-up etc. 


Management of notifications to various stakeholders by way of email or 
SMS, for example, permit holders, RTO about device not working, over- 
speeding, etc. 


Notification to the permit-holder through SMS in case any device stops 
functioning/sending data to the application. 


Capability to update the on-board devices’ firmware from the backend. 
Capability to configure on-board device parameters from the backend. 


The tracking data will be kept live in the system for at least 90 days. 
Utilities will be provided to support archive and restore functions for 
older data. Alerts/reporting shall be available for one year in the backend. 


The backend will store VTS time-related data at the same resolution as 
received in the live application. The archived data after 90 days can also 
be restored using utilities provided. 


From a security perspective, the devices will not communicate to any 
IP address located outside India whether it be the manufacturer’s 
application or for purposes of configuration or firmware updates. 


Firmware of the device needs to be available for auditing to notified 
testing agencies. Firmware binary should be made available with version 
matching one in the device as well as binary size and modification 
timestamp and/ or checksum should match for the binary provided and 
one installed on device. 


Backend system should be able to remotely read the existing version 
number of the firmware via an OTA configuration read command. A 
new version of the firmware should be pushed over the air from the VLT 
manufacturer’s application. This shall be verified by the backend system 
remotely reading the new version number of the firmware in the device 
via and OTA configuration read command. 


The device will communicate only to whitelisted set of IP addresses 
located in India and will receive communication and commands also 
from whitelisted set of IP addresses located in India. 
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u) The application and all key components like device management, 
firmware control, GIS map shall be hosted at a data centre/ cloud in India 
and it will be available for auditing by regulatory agencies. 


v) The system shall provide more than 99 percent availability and adhere 
to infrastructure security, vulnerability assessment and penetration 
testing guidelines as set out by Ministry of Electronics, Information and 
Technology, Govt of India. 


w) No data should flow out of the country under any circumstances in 
compliance with applicable laws/regulations/guidelines. 


— 


The common layer shall be got tested from the testing agencies 
specified in CMVR Rule 126/STQC/NIC for the following minimum 
functionalities: 


y 


1) Registration and activation of the device(s) fitted on the vehicle, 
including the details of vehicle registration number, engine number, 
chassis number, vehicle make and model, device make and model, 
and connectivity details (telecom service provider's name, ICCid, 
SIM Nos., IMSI, date of validity, etc.). 

2) Publish VLT device details in the VAHAN/ any other State/ 
UT system used for registration of vehicles and/or issuance of 
permits 

3) Re-registration/re-activation of the device(s) fitted on the vehicle in 
case of any change in device or telecom service provider, etc. 

4) Periodic health check of the device(s) fitted on the vehicle 
through SMS, as per A-4.2.3. 

5) Receiving alerts from VLT devices in case of defined deviations by 
vehicle such as over-speeding, etc. Publish alerts and health check 
received from VLT device in the VAHAN/ any other State/UT system 
used for registration of vehicles and/or issuance of permits. 

6) Provide interface to VAHAN, respective State/UTs, RTOs, testing 
agencies, VLT device manufacturer’s and their dealers. 

B Publish Data to Common Layer by VLT Device Manufacturers’ 
Applications (Sample) Requirement to be complied with by VLT device 
manufacturers’ applications 


Application shall publish the data to common layer in a specified frequency and 
format as mentioned below 
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Services to publish data to the common layer 
1. Push Offence Details 


Type à REST web service 
Data Type : JSON Array 
Frequency i lh 


A single request may contain JSON Array of maximum 500 JSON Objects of the 
following format. 


SI Key Value Length Description 
No. in bytes 
(1) (2) (3) (4) 
In Parameters 
i) oftyp 2 Offence Type 
OS= Overspeed 
ii) vno 16 Vehicle number without any delimiter 
like hyphen (-) or space. 
iii) imei 15 IMEI number. 
iv) date 8 Date in format DDMMYYYY 
v) time 6 UTC in format hhmmss 
vi) lat 12 Latitude, decimal not less than 6 places 
vii) latd 1 Latitude direction. N = North, S = South 
viii) lon 12 Longitude, decimal not less than 6 places 
ix) lond 1 Longitude direction. E= East, W = West 
x) spd 6 Speed in km/h, Up to One Decimal 
Value. 
xi) loc Location (Reverse Geo-coded) 
xii) rto RTO Code 
xii) state State Code 
Response 
xiv) resp OK/ Error 
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2. Push Alert Details 


Type : REST web service 
Data Type ] JSON Array 
Frequency : Ih 


A single request may contain JSON Array of maximum 500 JSON Objects of the 
following format. 


SI Key Value Length Description 
No. in bytes 
(1) Q) (3) (4) 
In Parameters 
1) | alrtid 2 Alert ID as per AIS-140 
ii) | vno 16 Vehicle number without any delimiter 
like hyphen (-) or space. 
iii) | imei 15 IMEI number. 
iv) | date 8 Date in format DDMMYYYY 
v) | time 6 UTC in format hhmmss 
vi) | lat 12 Latitude, decimal not less than 6 places 
vil) | latd 1 Latitude direction. N = North, S = South 
viii) | lon 12 Longitude, decimal not less than 6 places 
ix) | lond 1 Longitude Direction. E = East, W = West 
x) | spd 6 Speed in km/h, Up to One Decimal 
Value. 
xi) | loc Location (Reverse Geo-coded) 
xii) | rto RTO Code 
xiii) | state State Code 
Response 
xiv) | resp OK/ Error 
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A-8.4 Conformity of Production — Testing Parameters 


a) The VLT device manufacturers will get their devices tested and certified 


b 


Cc 


) 


— 


for conformity of production from the testing agencies referred to in Rule 
126 of the CMVR for compliance to the Rule 125 H of CMVR every 
year from the date of first certification. The parameters for testing shall 
be as specified in Table on Test for COP of VLT Device and Emergency 
Buttons given below. 


The VLT device manufacturers shall get their backend applications 
audited from the testing agencies referred to in Rule 126 of the CMVR/ 
STQC/NIC or by the agencies specified by States/UTs every year from 
the date of first certification. The parameters for auditing shall be as 
specified in the Table on Test Parameters for Auditing of VLT Device 
Manufacturer's Backend Application/System given in this clause. 


The testing agencies shall provide the details of the VLT devices and 
backend applications certified by them to the States/UTs by uploading 
the same on the respective backend systems or any other means. 


Test for COP of VLT Device and Emergency Buttons 


SI. No. Test Details (As per Annex A) 
(1) (2) 
1) Emergency button functionality [see A-3, (c) ] 


il) SMS fall back [see A-3, (d) ] 
ili) Functional Testing [see A-7.1, (a) to (h) ] 
iv) Performance Parametric Test [see A-7.2, (a) ] 
v) Protocol and alerts verification as per 
— A-2.3 and the table on health parameters, 
— Table 1 and 2 of A-4 
— Table on Page 8 of IS 16833, 
— OTA Commands verification [see A-2.2] 
vi) Ingress Protection (IP) Test [see A-7.2, (d) ] 
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Test Parameters for Auditing of VLT Device Manufacturer’s 


SI. No. 
(1) 


Backend Application/System 


Test Details (As per Annex A) 
(2) 


i) 


ii) 


iii) 


iv) 


v) 


vi) 


vii) 


Firmware over the air update. Backend application should be able 
to remotely read the existing version number of the firmware via an 
OTA configuration read command. A new version of the firmware 
should be pushed over the air. This should be verified by reading 
the new version number of the new firmware in the device via and 
OTA configuration read command. 


Application availability test to be conducted over a 7 day period by 
periodic check of availability randomly or at specified intervals in 
an automated or manual manner. 


Test functionality of application to allow user to map and un-map 
a device to a vehicle. 


Test functionality to track a vehicle on a map over a period of 8 h 
given either a device ID or vehicle registration number. The device 
ID and vehicle should be mapped beforehand. 


Test replay of a vehicles location by specifying a start and end date 
and time and device ID or vehicle registration number. The start 
and end date and time should be from within the last 3 months at 
date of test. In case 3 months of historical data is not available, the 
VLT manufacturer can pre populate test data for the duration. 


Firmware binary should be made available with version matching 
one in the device as well as binary size and modification timestamp 
and/ or checksum should match for the binary provided and one 
installed on device. 


Test to confirm geographical location of IP addresses, the device 
communicates with by IP Geolocation for all IPs configured 
into the device to confirm they are in India. The IPs configured 
should be read from the firmware configuration via configuration 
read command and also separately confirmed against a list of IPs 
provided by the VLT manufacturer. 


20 


SI. No. Test Details (As per Annex A) 


(1) (2) 

viii) VLT manufacturer to provide a certificate, statement or affidavit 
certifying the location of data centre/ cloud hosting region in India 
for user, device and vehicle data. 

ix) VLT manufacturer to provide a vulnerability analysis and 


penetration testing report from a third party test agency authorized 
by CERT-In/STQC. 


A-8.5 CRITERIA FOR EXTENSION OF TYPE APPROVAL 


In case of following changes, Functional, Performance, Durability and 
Environmental Tests which are necessary for establishing compliance are listed 
below: 


SI Changes in System Tests to be conducted 

No. 

(1) Q) (3) 

B1.1 Change in Make, Model, Type, Applicable tests as per A-6 and 
accompanied with or without Functional verification at system 
a Part No. of Vehicle Location integration level or component 
Tracking (VLT) and Vehicle Health level as applicable 
Monitoring. 

B1.2 Change in software of ITS System Functional verification at system 

integration level 
B1.3 Change in wiring harness Wiring harness requirements 


specified in this standard 


[ Page 17, clause B-2.1 (1) ] — Substitute the following for the existing: 


*]) The system should support any operational GNSS system (Location, speed, 
heading, time stamp) data polling and capable of sending this data at a frequency 
shall be 5 s during vehicle operation and not less than 10 min in sleep/ Ignition off 
a per protocol defined in B-4. 
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Device shall be capable for operating in L and/or S band and include support 
for NAVIC/IRNSS (Indian Regional Navigation Satellite System) for devices 
installed on vehicles on or after 1st April 2019. However ATD devices shall be 
compliant as per other GNSS constellation in the interim period.’ 


[ Page 18, clause B-2.1 (5) ] — Substitute the following for the existing: 


*5) The system's GNSS module shall have an acquisition sensitivity of equal to 
or better than (-) 145 dBm with GNSS/ (-)140 dBm with IRNSS (NAVIC as 
applicable.).’ 


[ Page 18, clause B-2.1 (6) ] — Substitute the following for the existing: 


*6) The system's GNSS module shall have a tracking sensitivity equal to or better 
than (-) 160 dBm with GNSS / (-)153 dBm with IRNSS (NAVIC as applicable). 


[ Page 18, clause B-2.1 (8) ] — Substitute the following for the existing: 


*8) The system's GNSS module should have: 
a) The capability of hot start « 10s 
b) The capability of warm start « 60s 
c) The capability of cold start < 120s’ 


[ Page 18, clause B-2.1 (9) ] — Substitute the following for the existing: 


*9) Should support standard digital I/O: 4 digital, 2 analogue input and 1 serial 
communication, (for example, RS232) for interfacing external systems (for 
example, digital input for emergency request button interfacing) and output for 
triggering other devices like hooter/flash light etc." 


[ Page 18, clause B-2.1 (12) ] — Substitute the following for the existing: 


*12) The system's Cellular module should have: 
a) Multi slot GPRS with In - Built quad-band GPRS module/modem 
b) GPRS class 10 or above 


c) Support embedded SIM/UICC (As per as per GSMA guidelines / DoT 
(TEC) Guidelines) to cater to the automotive operational requirement 
such as vibration, temperature and humidity and provide long life span 
with at least 10 years life and more than 1 million read/write cycles 

d) GPRS module and embedded SIM/UICC: 


1) Shall support SMS, data (GPRS, TCP/IP) and 


wn 
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2) Support multiple network OTA switching (on-demand/ automatic) 
capabilities.’ 


[ Page 18, clause B-2.1 (16) ] — Substitute the following for the existing: 


*16) System shall be capable to operate with vehicle battery input voltage 12VDC 
and or 24VDC.’ 


[ Page 19, clause B-2.3] — Substitute the following for the existing clause: 


*B-2.3 Configuration of Device Parameters Over the Air (OTA) 


The device at least support below parameters should be configurable over 
the air (through SMS or Cellular). The update shall be allowed only over an 
*authenticated' channel: 


a 


b 
c) 


— — 


d) 
e) 
f) 


g) 
h) 


j 


k) 


Setting/ Change of the primary or secondary IP and port number 
Setting/Change of the APN 


Set configuration parameter like sleep time, over speed limit, harsh 
braking, harsh acceleration, rash turning threshold limits, etc. 


Emergency control and activation/ health check control SMS centre 
number(s), 


Configuring the vehicle registration number, 


Configuring the frequency of data transmission in normal / Ignition state / 
OFF state sleep mode/ health check message on SMS / emergency 
state, etc. 


Configuration of time duration for emergency state, 
Capacity to reset device, 


Command to get the IMEI (International Mobile Station Equipment 
Identity)/ health status of the device, 


CLR: For clearing certain commands, alarms, alerts, etc, except 
emergency alert. 


SET: For setting parameters, 


GET: For enquiring regarding the parameters such as mobile number, 
GSM strength, vehicle number and other important parameters. 


After each SET, GET, CLR command the device should send alert to backend 
control centre, as mentioned in B-4 , giving the details of mode, mobile no/ IP of 
control centre sending commands.’ 
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(Page 20, clause B-4.1, line 11) — Substitute the following for the existing 
matter: 


“but can be in any sequence and with any separator? 


[ Page 21, Table 7, SI No. v) | — Substitute the following for the existing 
matter: 


SI No. Field Description Sample Data 
0) (2) (3) (4) 
v) Packet Type Specify the packet type — NR 
NR = Normal 
EA = Emergency alert 
TA = Tamper alert 
HP = Health packet 
IN = Ignition on 
IF = Ignition off 


BD = Vehicle battery disconnect 
BR = Vehicle battery reconnect 
BL = Internal battery low 

HB = Harsh breaking, 

HA = Harsh acceleration 

RT = Rash turning 


[ Page 23, clause B-4.2, Informal Table, SI. No. ii), iii) and iv) | — Substitute 
the following for the existing matter: 


SI No. Attribute Value/Description Size 


Message Types supported. Character, 2 bytes 
ii) Packet type Emergency Message (EMR)or 
Stop Message (SEM) 


Unique ID of the Vehicle Character, 15 bytes 
(IMEI Number) 


NM - Normal packet, SP — Character, 2 bytes 
Stored packet 


iii) IMEI No 


iv) Packet Status 
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(Page 24, clause B-5.1) — Substitute the following for the existing matter: 


*B-5.1 VLT Device Location 


The VLT system shall be mounted in a suitable location such a way that it is not 
easily accessible /exposed to passengers. 


This requirement shall not be applicable in case of combined systems VLT with 
HMI (Human Machine Interface) display in front of driver.’ 


(Page 24, clause B-5.4) — Substitute the following for the existing matter: 


*B-5.4 Emergency Button requirements and Physical Mounting 


Emergency button(s) shall be fitted in such a way that every passenger including 
driver shall be able to access the Emergency button(s). Passenger Car shall have 
at least one emergency buttons on each passenger row easily accessible by each of 
the passenger. There shall also be one dedicated emergency button for the driver 
row. Passenger Transport bus shall have emergency buttons at locations easily 
visible and accessible to all the passengers such as every 2 m on both the sides 
on passenger seating area. For seats reserved for ladies there shall be a dedicated 
panic button for each row. It shall be permissible to have a single emergency 
button for two successive ladies’ rows on both sides of the vehicle provided each 
lady passenger in either rows are able to reach and operate the emergency button. 


In case of passenger transport bus which has a glass window covered between 
two pillars having pitch 2m or more, the emergency buttons shall be provided on 
each pillar. National Permit Trucks, shall have one dedicated emergency button 
for the driver row.’ 


(Page 24, clause B-6) — Substitute ‘DEVICE LEVEL FUNCTIONAL, 
PERFORMANCE AND DURABILITY TESTS’ for ‘TESTS?’ in the heading. 


[ Page 24, clause B-6 (a) and b) ] — Delete. 


(Page 24, clause B-6.1) — Substitute ‘List of Tests’ for ‘Type Tests’ in the 
heading. 


(Page 24, clause B-4.1, line no 1) — Delete. 


[ Page 24, clause B-6.2 (see also Amendment No. 1) | — Delete. 
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[ Page 25, clause B-7.1 (f) and g) (see also Amendment No. 1) |— Substitute 
the following for the existing matter: 


*f) Acquisition sensitivity test — Acquisition sensitivity refers to the minimum 
signal level at which the device is able to successfully perform a cold start 
TTFF. The acquisition sensitivity test is a simulated signal test. A device cold 
start is performed, and the time to acquisition is measured. Signal levels are then 
progressively increased. Allow the receiver to successfully perform cold start 
TTFF. The minimum signal level is referred as to be acquisition sensitivity. This 
signal strength is recorded. 


Acceptance criteria: The acquisition sensitivity shall be minimum (-) 145 dBm 
with GNSS/ (-) 140 dBm with IRNSS (NAVIC as applicable.). 


g) Tracking sensitivity test — Tracking sensitivity refers to the minimum signal 
level at which the device is able to successfully maintain the location fix. The 
tracking sensitivity test is a simulated signal test. Test setup for the tracking 
sensitivity receiver test is as shown in Fig. 3. The device under this test is 
locked on to the simulator’s output frequency and the simulator power output is 
lowered until the lock is lost. Multiple repetition of the test with different satellite 
geometries ensures that an accurate average measure is recorded. 


Acceptance Criteria: The tracking sensitivity shall be equal to or better than (-) 
160 dBm with GNSS / (-) 153 dBm with IRNSS (NAVIC as applicable).’ 


[ Page 26, clause B-7.1 (j) (see also Amendment No. 1) | — Substitute the 
following for the existing matter: 


‘j) On vehicle dynamic location test — VLT devices will be mounted on any 
target vehicle connected with vehicle battery. Target vehicle with VLT devices 
will be run for 10 km on pre-defined track/route to verify dynamic location test. 
VLT device PVT data shall be within + 12 m for more than 90 percent of the fixed 
location data." 


[ Page 31, clause B-7.4, SI No. ii), iti) and iv) ] — Substitute the following 
for the existing matter: 


SI No. Attribute Value/Description Size 


(1) Q) (3) (4) 
ii) Packet type Message Types supported. Character, 2 bytes 
Emergency Message (EMR) 


or Stop Message (SEM) 
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SI No. Attribute Value/Description Size 


(1) Q) (3) (4) 

iii) IMEI No Unique ID of the Vehicle Character,15 bytes 
(IMEI Number) 

iv) Packet Status NM — Normal packet, SP — Character, 2 bytes 
Stored packet 


(Page 32, clause C-1) — Substitute the following for the existing clause: 


*C-1 GENERAL 


This annex will be applicable only to those buses which are fitted with GPS 
tracking devices as per Annex A. It primarily covers the functional specifications, 
test and protocol requirements of “CCTV system with an integrated emergency 
system for buses.’ 

[ Page 33, clause C-5.2 (18) ] — Insert the following at the end: 


‘The devices installed on or before 31 August 2020 may support embedded SIM 
or Plastic SIM for the above requirement. Plastic SIM and recorder to be tested 
along with SIM as per tests prescribed elsewhere in the Standard. The status shall 
be reviewed before the end of the stipulated period.’ 


[ Page 33, clause C-5.2 (19) ] — Delete. 
[ Page 33, clause C-5.2 (20) ] — Delete. 


[ Page 34, clause C-5.3 (2) ] — Substitute the following for the existing 
matter: 
*2) The IP camera shall have minimum 3.6 mm lens.’ 

[ Page 35, clause C-5.4 (4) ] — Substitute the following for the existing 
matter: 


‘4) The mNVR shall support H.264 or H.265 or later video compression 
algorithm." 
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[ Page 35, clause C-5.4 (11) ] — Substitute the following for the existing 
matter: 


*11) The mNVR will record location and time in normal, schedule based, alarm 
triggered and motion detection mode. Alarms triggered modes may include 
alarms triggered via digital I/O input, for example, emergency button, emergency 
door open, brake on, reversing, DVR enclosure open.’ 


[ Page 35, clause C-5.4 (14) ] — Substitute ‘or’ for ‘and’. 
[ Page 35, clause C-5.4 (15) (c) ] — Substitute the following for the existing 
matter: 


*c) Built-in 4G module, supporting 2G/3G/4G (at least 900, 1 800 and 2100 MHz 
frequency bands), support for SMS, voice, data (GPRS, TCP/IP) with multiple 
network OTA switching capabilities." 

[ Page 35, clause C-5.4 (16) ] — Insert the following at the end: 


‘The devices installed on or before 31 August 2020 may support embedded SIM 
or Plastic SIM for the above requirement. The status shall be reviewed before the 
end of the stipulated period.’ 


[ Page 35, clause C-5.4 (17) ] — Delete. 
[ Page 35, clause C-5.4 (19) ] — Delete. 


[ Page 35, clause C-5.4 (25) ] — Substitute the following for the existing: 
*25) The mNVR shall be capable of detecting any type of video tempering or the 
system shall be capable of detecting any type of video tampering.’ 

(Page 35, clause C-5.4) — Insert the following new clause: 


*36) The mNVR shall have tamper proof watermark or it shall be capable of 
detecting any type of tampering. 


NOTE — Functions mentioned above could also be alternatively provided by ATD as per Annex 
A or this feature could also be demonstrated through in-built feature of ATD as per Annex A.” 


[ Page 36, clause C-6, SI No. 1) (a) ] — Insert the following at the end: 


‘either physical or on a touch screen,’ 
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(Page 38, clause C-7.1.3, Table) — Substitute ‘Any microphone disconnect. 
Requirement of microphone multi-function status indication may be exempted if 
microphone is inbuilt in the camera.’ for ‘Any microphone disconnect’. 


(Page 38, clause C-7.1.4, Table) — Insert the following at the end of the 
table: 


‘NOTE — Ignition On, Ignition Off, Harsh Braking, Harsh Acceleration and Rash Turning 
Alerts can alternatively be also be provided by vehicle tracking devices approved as per Annex 
AY 


[ Page 40, clause C-8 (20) ] — Substitute ‘High voltage test (see C-10.2.4).’ 
for the existing matter. 


[ Page 40, clause C-8 (35) | — Delete. 


(Page 42, clause C-10.1.4) — Substitute the following for the existing matter: 


*C-10.1.4 /P Camera Video Compression Support 
Applicable for: IP Cameras. 


The IP CCTV cameras should support H.264 or H.265 or later, MPEG-4 and 
M-JPEG video compression standards. The IP CCTV cameras will be tested for 
supporting all these compression standards. The future IP CCTV cameras which 
support H.264 or H.265 or later video compression standard will be tested for 
this also. 


Acceptance criteria: The IP CCTV camera should support H.264 or H.265 or 
later, MPEG-4 and MJPEG video compression standards. The future IP CCTV 
cameras should support H.265 or later video compression standard also.’ 


(Page 42, clause C-10.1.6) — Insert the following at the end of the clause: 


"The supplier would provide self-certification for the above specification." 


(Page 42, clause C-10.1.7) — Substitute *H.264 or H.265, or later’ for 
*H.264’ 


(Page 44, clause C-10.1.16) — Substitute the following for the existing 
matter: 


‘Applicable for: IP Cameras/mNVR/Hybrid. 
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The IP CCTV cameras and mNVR should be ONVIF profile S compliant. The 
IP CCTV cameras and mNVR will be tested for compliance to ONVIF profile S 
standards. 


Acceptance criteria: The IP CCTV camera and mNVR should be compliant to 
ONVIF profile S standards. 


NOTE — Wherever the Test method is not specified, supplier will demonstrate the compliance 
to the satisfaction of test agency’ 


(Page 44, clause C-10.2.1, line 15) — Substitute ‘tracking functionality’ for 
‘functional’. 


(Page 45, clause C-10.2.2, line 19) — Substitute ‘tracking functionality’ for 
‘functional’. 


(Page 45, clause C-10.2.4,) — Rename test as ‘High voltage test’ in place of 
‘Over voltage protection test’. 


(Page 45, clause C-10.3.1, line 10) — Substitute ‘tracking functionality’ for 
‘functional’. 


(Page 45, clause C-10.3.1) — Insert the following at the end of the clause: 


‘Device should be free from any kind of deformation, cracks, damage, etc.’ 


(Page 46, clause C-10.3.2, line 9) — Substitute ‘tracking functionality’ for 
‘functional’. 


(Page 46, clause C-10.3.2) — Insert the following at the end of the clause: 
‘Device should be free from any kind of deformation, cracks, damage, etc.’ 


(Page 46, clause C-10.3.3, line 10) — Substitute ‘tracking functionality’ for 
‘functional’. 


(Page 46, clause C-10.3.3) — Insert the following at the end of the clause: 


‘Device should be free from any kind of deformation, cracks, damage, etc.’ 


(Page 46, clause C-10.3.5, line 12) — Substitute *tracking functionality? for 
‘functional’. 
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(Page 46, clause C-10.3.5) — Insert the following at the end of the clause: 


‘Device should be free from any kind of deformation, cracks, damage, etc.’ 


(Page 46, clause C-10.3.6, line 8) — Substitute ‘tracking functionality’ for 
‘functional’. 


(Page 46, clause C-10.3.6) — Insert the following at the end of the clause: 
‘Device should be free from any kind of corrosion’. 


(Page 47, clause C-10.3.10, line 5) — Substitute ‘tracking functionality’ for 
‘functional’. 


(Page 47, clause C-10.3.10) — Insert the following at the end of the clause: 
‘Device should be free from any kind of deformation, cracks, damage, etc.’ 

(Page 47, clause C-10.4) — Delete. 

(Page 47, clause C-11) — Delete. 

(Page 47, Table 14) — Delete. 

(Page 48, clause C-12) — Delete. 

(Page 48, Table 15) — Delete. 


[ Page 50, clause D-2.2 (5) ] — Substitute the following for the existing 
matter: 


*5) The mDVR shall support H.264 or H.265 or later video compression 
algorithm." 


[ Page 50, clause D-2.2 (16) (c) | — Substitute the following for the existing 
matter: 


*c) Built-in 4G module, supporting 2G/3G/4G (at least 900, 1 800 and 2 100 MHz 
frequency bands), 


Support for SMS, voice, data (GPRS, TCP/IP) with multiple network OTA 
switching capabilities.’ 
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[ Page 52, clause D-2.3 (5) ] — Substitute the following for the existing 
matter: 


*5) The system's GNSS module shall have an acquisition sensitivity of minimum 
(-) 145 dBm with GNSS/ (-) 140 dBm with IRNSS (NAVIC as applicable). 


[ Page 52, clause D-2.3 (6) | — Substitute the following for the existing 
matter: 


*6) The system's GNSS module shall have a tracking sensitivity of minimum (-) 
160 dBm with GNSS / (-) 153 dBm with IRNSS (NAVIC as applicable).’ 


[ Page 52, clause D-2.3 (8) ] — Substitute the following for the existing 
matter: 


*8) The system should have, 
a) the capability of hot start «10s, 
b) the capability of warm start «60s, and 
c) the capability of cold start <120s. 
The above timing is applicable after DVR boots up.’ 


[ Page 52, clause D-2.4 (5) (see also Amendment No. 1) | — Substitute 
‘later’ for ‘latter’. 


[ Page 53, clause D-2.5 (4) ] — Substitute the following for the existing 
matter: 
‘4) The mNVR shall support H.264 or H.265 or later video compression 
algorithm.’ 

[ Page 53, clause D-2.5 (14) ] — Substitute ‘or’ for ‘and’. 

[ Page 53, clause D-2.5 (15) (c) ] — Substitute the following for the existing 
matter: 


*Built-in 4G module, supporting 2G/3G/4G (at least 900, 1 800 and 2 100 MHz 
frequency bands), Support for SMS, voice, data (GPRS, TCP/IP) with multiple 
network OTA switching capabilities.’ 


(Page 53, clause D-2.5) — Insert the following at the end: 


*36. The mNVR shall have tamper proof watermark or it shall be capable of 
detecting any type of tampering. 
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NOTE — Functions mentioned above could also be alternatively provided by ATD as per Annex 
A or this feature could also be demonstrated through in-built feature of ATD as per Annex A.” 


[ Page 54, clause D-2.6 (1) ] — Substitute the following for the existing: 


*]) The system should support any operational GNSS system (Location, speed, 
heading, time stamp) data polling and capable of sending this data at a frequency 
of less than or equal to 10 s. The devices installed on or after 1* January 2020 
should also support Indian Regional Navigation Satellite System (IRNSS).’ 


[ Page 55, clause D-2.6 (5) ] — Substitute the following for the existing 
matter: 
*5) The system's GNSS module shall have an acquisition sensitivity of minimum 
(-) 145 dBm with GNSS/ (-) 140 dBm with IRNSS (NAVIC as applicable). 

[ Page 55, clause D-2.6 (6) | — Substitute the following for the existing: 
*6) The system's GNSS module shall have a tracking sensitivity of minimum (-) 
160 dBm with GNSS / (-) 153 dBm with IRNSS (NAVIC as applicable). 

[ Page 55, clause D-2.6 (8) | — Substitute the following for the existing 
matter: 
*8) The system should have: 

a) The capability of hot start «10s, 

b) The capability of warm start «60s, and 

c) The capability of cold start <120s. 
The above timing is applicable after mNVR boots up.’ 


(Page 55, clause D-2.6) — Insert the following at the end: 


*12) Specifications for VTD in case of Inbuilt MNVR will comply with all 
requirements given in Annex A 


13) Code of Practice shall also include procedure for replacement of any faulty 
V'TD device during the warranty period." 
(Page 55, clause D-3) — Insert the following at the end: 


"The emergency buttons will be connected in a manner such that in case of press 
of any emergency button, both mNVR and the vehicle tracking device get the 
alert signal.’ 
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[ Page 55, clause D-4.1 (a) ] — Insert the following at the end: 


‘either physical or on a touch screen,’ 


(Page 58, clause D-5.2.4, Table) — Insert the following at the end of the 
table: 
“NOTES: 
1 Requirement of microphone multi-function status indication may be exempted if microphone 
is inbuilt in the camera. 
2 Ignition status may be provided via VTD device also 
3 Location of camera shall be obtained from VTD.’ 


(Page 59, clause D-5.3, Table) — Insert the following at the end of the table: 


‘NOTE — Ignition On, Ignition Off, Harsh Braking, Harsh Acceleration and Rash Turning 
Alerts can alternatively be also be provided by Vehicle Tracking Devices Approved as IS 16833 
Annex A.” 


following for the existing matter: 


SI No. Attribute Value/Description Size 


Message Types supported. Character, 2 bytes 
ii) Packet type Emergency Message (EMR) 


or Stop Message (SEM) 
ids Unique ID of the Vehicle Character, 15 bytes 
iii) IMEI No (IMEI Number) 
i Packet Status NM - Normal packet, SP — Character, 2 bytes 
Stored packet 


(Page 62, clause D-6) — Substitute ‘Device Level Functional, Performance 
and Durability Tests’ for ‘Type Test’ in the heading. 


(Page 63, clause D-7) — Delete. 
(Page 64, clause D-8.1.4) — Substitute the following for the existing clause: 


‘D-8.1.4 IP Camera Video Compression Support 
Applicable for: IP Cameras. 
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The IP CCTV cameras should support H.264 or H.265 or later, MPEG-4 and 
M-JPEG video compression standards. The IP CCTV cameras will be tested for 
supporting all these compression standards. The future IP CCTV cameras which 
support H.264 or H.265 or later video compression standard will be tested for 
this also. 


Acceptance criteria: The IP CCTV camera should support H.264 or H.265 or 
later, MPEG-4 and MJPEG video compression standards. The future IP CCTV 
cameras should support H.265 or later video compression standard also.’ 


(Page 63, clause D-8.1.6) — Substitute the following for the existing clause: 


‘D-8.1.6 JP Camera Audio Compression Support 
IP Camera Audio Compression Support 
Applicable for: IP cameras. 


The IP CCTV cameras should support G.711 or G.726 audio compression 
standards. 


Acceptance criteria: The supplier shall provide self-certification for the above 
specification." 


(Page 64, clause D-8.1.7) — Substitute the following for the existing clause: 


'D-8.1.7 mDVR/mNVR Video Compression Support 
Applicable for: mDVR/mNVR/Hybrid. 


The mDVR/mNVR/Hybrid should support H.264 or H.265, or later video 
compression algorithm. 


Acceptance criteria: The supplier would provide self certification for the above 
specification." 


(Page 66, clauseD-8.1.16) — Substitute ‘The IP CCTV cameras and mNVR 
should be ONVIF profile S compliant.’ for ‘The IP CCTV cameras and mNVR 
should be ONVIFprofile S compliant to ensure integration of IP CCTV equipment 
from different suppliers.’ 


(Page 66, clause D-8.2.1, line 14) — Substitute ‘tracking functionality’ for 
‘functional’. 


(Page 67, clause D-8.2.2, line 18) — Substitute ‘tracking functionality’ for 
‘functional’. 
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(Page 67, clause D-8.2.2, line 30) — Substitute ‘tracking functionality’ for 
‘functional’. 


(Page 67, clause D-8.2.4) — Rename test as “high voltage test’ in place of 
‘Over voltage protection test’. 


(Page 68, clause D-8.3.1, line 10) — Substitute ‘tracking functionality’ for 
‘functional’. 


(Page 68, clause D-8.3.2, line 9) — Substitute ‘tracking functionality’ for 
‘functional’. 


(Page 68, clause D-8.3.3, line 11) — Substitute ‘tracking functionality’ for 
‘functional’. 


(Page 68, clause D-8.3.5, line 12) — Substitute ‘tracking functionality’ for 
‘functional’. 


(Page 68, clause D-8.3.6, line 9) — Substitute ‘tracking functionality’ for 
‘functional’. 


(Page 68, clause D-8.3.6) — Insert the following at the end of the clause: 


‘Device should be free from any kind of corrosion’. 


(Page 68, clause D-8.3.7, line 9) — Substitute “tracking functionality’ for 
‘functional’. 


(Page 68, clause D-8.3.9, line 16) — Substitute ‘tracking functionality’ for 
‘functional’. 


(Page 69, clause D-8.3.10, line 5) — Substitute ‘tracking functionality’ for 
‘functional’. 


(Page 68, clause D-8.3.1) — Insert the following at the end of the clause: 


‘Device should be free from any kind of corrosion’. 


(Page 68, clause D-8.3.2) — Insert the following at the end of the clause: 


‘Device should be free from any kind of corrosion’. 
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(Page 68, clause D-8.3.3) — Insert the following at the end of the clause: 


‘Device should be free from any kind of corrosion’. 


(Page 68, clause D-8.3.5) — Insert the following at the end of the clause: 


‘Device should be free from any kind of corrosion’. 


(Page 68, clause D-8.3.10) — Insert the following at the end of the clause: 


‘Device should be free from any kind of corrosion’. 


(Page 69, clause D-8.4) — Insert the following at the end of the clause: 


"The above given requirements may be demonstrated on any server.’ 


(Page 69, clause D-8.4) — Insert the following at the end of the clause: 


*Protocol is a set of rules to be followed by the device while sending data to 
the backend. The protocol comprises data update rate, number of fields, start 
character, end character, alert type, etc. Protocol testing involves checking the 
compliance of data sets received by the backend against the protocol both with 
respect to the data fields as well the format. It is expected that the data coming to a 
central server should be exactly as required under the protocol. Table 17 mentions 
the validation process for the protocol communication. The following test would 
be performed along with the protocol testing of the device: 


a) Memory storage — The device should support 40 000 or more positional 
logs/packets. This is a functional test and the device will be simulated 
to be in non — GPRS coverage area and the logs will be maintained. The 
capacity of logging will be checked by monitoring the logs on the device. 


b 


wm 


Messages and alerts from devices — Table 18 contains the listing of alerts 
that need to come from the tracking devices. These alerts are applicable 
for both live packets as well as the history packets. The above given 
requirements may be demonstrated on any server.’ 


(Page 69, clause D-9.1.1(see also Amendment No. 1)) — Substitute the 
following for the existing: 


'D-9.1.1 Functional Testing 


Functional testing will be carried out to assess the performance of the tracking 
device on important functional aspects as below: 
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a) 


b) 


c) 


d) 


e) 


Tracking functionality test — The test shall be conducted on VTL to 
determine the proper functioning of VLT with emergency button by 
testing its connectivity to backend control centre (Government authorized 
server). 


Procedure: The system with emergency button shall be connected to 
vehicle battery to switch it on. The VLT with emergency button shall 
be tested for the connectivity to server and its capability to send two 
location messages. 


Location accuracy test — This test shall be conducted on VLT with 
emergency button. The receiver is placed into a cold start state, usually 
by a command sent to the receiver through a test connection, and then a 
fairly strong navigation signal simulating in L and/or S band is sent. The 
time it takes for the receiver to determine its first good location fix is 
recorded. Test is done many times (>15 times) over many conditions and 
the results are averaged. 


Acceptance Criteria: 2.5 m CEP or 6m 2DRMS 


Cold-start time to first fix (TTFF) test — This test is used to determine 
the time taken for first fix during a cold start of the device. The device in 
this test is placed into a cold start state. The time it takes for the device 
to determine its first good location fix is recorded. The cold start test is 
performed several times and the results are averaged. 


Acceptance Criteria: The cold start TTFF shall be less than 120 s at Open 
Sky condition or (-) 130 dBm. 


Warm-start time to first fix test — This test is used to determine the time 
taken for first fix during a warm start of the device. In this test the device 
is started in warm start mode and time taken by device to determine the 
first valid location fix is recorded. This is done several times and results 
are averaged. 

Acceptance Criteria: The warm start TTFF should be less than 60 s at (-) 
130 dBm 

Hot-start time to first fix test — This test is used to determine the time 
taken for first fix during a hot start of the device. In this test the device is 
started in hot start mode and time taken by device to determine the first 
valid location fix is recorded. This test is performed several times and 
results are averaged. 


Acceptance Criteria: The hot start TTFF should be less than 10 s. 
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f) Acquisition sensitivity test — Acquisition sensitivity refers to the 


8 


a 


minimum signal level at which the device is able to successfully perform 
a cold start TTFF. The acquisition sensitivity test is a simulated signal 
test. A device cold start is performed, and the time to acquisition is 
measured. Signal levels are then progressively decreased until the device 
can no longer acquire the location. This signal strength is recorded. 


Acceptance Criteria: The acquisition sensitivity shall be minimum (-) 
145 dBm with GNSS/ 140 dBm with IRNSS (NAVIC as applicable.). 


Tracking sensitivity test — Tracking sensitivity refers to the minimum 
signal level at which the device is able to successfully maintain the 
location fix. The acquisition sensitivity test is a simulated signal test. Test 
setup for the tracking sensitivity receiver test is as shown in Fig. 3. The 
device under this test is locked on to the simulator’s output frequency 
and the simulator power output is lowered until the lock is lost. Multiple 
repetition of the test with different satellite geometries ensures that an 
accurate average measure is recorded. 


Acceptance Criteria: The tracking sensitivity shall be equal to or better 
than (-) 160 dBm with GNSS / 153 dBm with IRNSS (NAVIC as 
applicable). 


h) Functional endurance test — VLT device shall be operated for 96 h 


j 


k 


wa 


— 


with external power supply and internal battery connected to device. 
PVT data monitoring will be done for complete duration of test with 
data frequency defined after IGN switch ‘ON’ mode. VLT device shall 
function successfully during and after test. 


On vehicle dynamic location test — VLT devices will be mounted on 
any target vehicle connected with vehicle battery. Target vehicle with 
VLT devices will be run for 10 km on pre-defined track/route to verify 
dynamic location test. VLT device PVT data shall be within + 6.0 m for 
more than 90 percent of the fixed location data. 


SIM testing — This test is to check the suitability of the SIM and 
communication module. The test shall be conducted to determine the 
effectiveness and operation of the GPRS module with OTA network 
switching capabilities on demand as well as automatically in real-time. 
The device would be tested to perform as per the protocol using an 
embedded SIM/UICC. The GPRS module and SIM, shall support SMS 
and Data (GPRS, TCP/IP). 
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Acceptance Criteria: In the testing, vendors has to demonstrate the embedded 
SIM/UICC based tracking and multiple network OTA switching capabilities (On 
demand as well as automatic switching on real-time basis) for effective network 
management and transmission.’ 


(Page 72, clause D-9.1.2) — Delete. 


(TED 28) 


Publication Unit, BIS, New Delhi, India 
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